1. Field of the Invention
This invention relates to network computing, and more particularly to the dynamic generation of Stubs and Ties for remote method invocations in RMI-IIOP implementations.
2. Description of the Related Art
RMI
RMI (Remote Method Invocation) is a way that a programmer, using the Java programming language and development environment, can write object-oriented programs in which objects on different computers can interact in a distributed network. RMI is the Java version of what is generally known as a remote procedure call (RPC), but with the ability to pass one or more objects along with the request. The object can include information that will change the service that is performed in the remote computer. The object parameter-passing mechanism may be referred to as object serialization. An RMI request is a request to invoke the method of a remote object. The request has the same syntax as a request to invoke an object method in the same (local) computer. In general, RMI is designed to preserve the object model and its advantages across a network.
RMI may be implemented as three layers:                A Stub (proxy) program in the client side of the client/server relationship, and a corresponding skeleton or Tie at the server end. The Stub appears to the calling program to be the program being called for a service.        A Remote Reference Layer that can behave differently depending on the parameters passed by the calling program. For example, this layer can determine whether the request is to call a single remote service or multiple remote programs as in a multicast.        A Transport Connection Layer, which sets up and manages the request.        
A single request travels down through the layers on one computer and up through the layers at the other end.
CORBA, IIOP, and ORB
IIOP (Internet Inter-ORB Protocol) is a protocol that makes it possible for distributed programs written in different programming languages to communicate over the Internet. IIOP is a critical part of an industry standard, the Common Object Request Broker Architecture (CORBA). CORBA is an architecture and specification for creating, distributing, and managing distributed program objects in a network. CORBA allows programs at different locations and developed by different vendors to communicate in a network through a broker that mediates remote requests.
An essential concept in CORBA is the Object Request Broker (ORB). An Object Request Broker (ORB) acts as a “broker” between a client request for a service from a distributed object or component and the completion of that request. ORB support in a network of clients and servers on different computers means that a client program (which may itself be an object) can request services from a server program or object without having to understand where the server is in a distributed network or what the interface to the server program looks like. Using ORBs, components can find out about each other and exchange interface information as they are running. To make requests or return replies between the ORBs, programs may use the General Inter-ORB Protocol (GIOP) and, for TCP/IP, Internet Inter-ORB Protocol (IIOP). IIOP maps GIOP requests and replies to the Internet's Transmission Control Protocol (TCP) layer in each computer. CORBA and IIOP assume the client/server model of computing in which a client program makes requests and a server program waits to receive requests from clients.
An object adapter is a subcomponent in ORB that connects a request using an object reference with the proper code to service that request. The Portable Object Adapter, or POA, is a particular type of object adapter that is defined by the CORBA specification. A POA object manages the implementation of a collection of objects. The POA supports a name space for the objects, which are identified by Object IDs. A POA also provides a name space for POAs. A POA is created as a child of an existing POA, which forms a hierarchy starting with the root POA. POAs may be transient or persistent.
RMI-IIOP
When a client communicates with a server using the IIOP protocol to access RMI objects on the server, the communication process may be referred to as RMI-IIOP because calls from the client target RMI objects on the server, and access to the RMI objects on the server is enabled through an IIOP mechanism.
IDL
Java Interface Definition Language (IDL) adds CORBA capability to the Java platform, providing standards-based interoperability and connectivity. Java IDL enables distributed Java applications to transparently invoke operations on remote network services using the industry standard OMG IDL (Object Management Group Interface Definition Language) and IIOP. Java IDL technology may be used by CORBA programmers who want to program in the Java programming language based on interfaces defined in CORBA Interface Definition Language (IDL).
EJB
Enterprise JavaBeans (EJB) is an architecture for setting up program components, written in the Java programming language, that run in the server parts of a computer network that uses the client/server model. Enterprise JavaBeans offers enterprises the advantage of being able to control change at the server rather than having to update each individual computer with a client whenever a new program component is changed or added. EJB components have the advantage of being reusable in multiple applications. To deploy an EJB component, it must be part of a specific application, which is called a container. The application or container that hosts the EJBs may be referred to as an application server. A typical use of EJBs is to replace Web programs that use the common gateway interface (CGI) and a Practical Extraction and Reporting Language (PERL) script. Another general use is to provide an interface between Web users and a legacy application mainframe application and its database.
RMIC
RMIC (RMI Compiler) is a Java RMI Compiler. RMIC generates Stubs, skeletons, and Ties for remote objects using either the JRMP or IIOP protocols. RMIC also generates OMG IDL. The RMIC compiler generates Stub and skeleton class files (JRMP protocol), and Stub and Tie class files (IIOP protocol) for remote objects. These class files are generated from the compiled Java programming language classes that contain remote object implementations. In Java, a remote object is one that implements the interface java.rmi.Remote.
FIG. 1 is a block diagram illustrating a conventional RMI-IIOP implementation. A client process 110 is shown using RMI-IIOP through client-side ORB 114 and server-side ORB 104 to access EJB(s) 106 on container 100. A container 100 is an entity that provides life cycle management, security, deployment, and runtime services to objects such as EJBs. Stubs 112 on the client side and Ties 102 on the server side provide the interfaces for the client process 110 to remotely invoke methods provided by EJB(s) 106 on the server side. Client-side ORB 114 and server-side ORB 104 handle the communication of the requests and response messages generated by the remote method invocations using RMI-IIOP.
Remote Method Invocation (RMI) systems such as RMI-IIOP conventionally rely on tools such as RMI Compiler (RMIC) to statically generate Stubs 112 and Ties 102. A conventional model for RMI is to first compile a remote interface and its implementation, and then use RMIC or a similar tool to generate static Stubs, skeletons and Ties. This requires that RMIC analyze a lot of information, either by using a Java compiler front end, or by using a library that enables the reading of class files. RMIC must then write out a number of Java source files for Stubs and Ties to a file system, and then finally invoke the Java compiler to generate the class files for the Stubs and Ties, which are then loaded in the usual manner through a ClassLoader.